@daniel - Fair enough, I’ll think about switching from UDP to TCP (or BLE). I haven’t explored the sleep duration thoroughly, it’s set to 100ms at the moment, which has been reliable enough for my purposes. Presumably this would be an issue for any networking stack on any machine, but we don’t think about it because we aren’t focused on putting a workstation to sleep immediately following a sendto(). Many thanks, Tim

@jmarcelino Ok that makes sense. ADC threshold sounds great, as does a simple GPIO-based pulse counter in case you're looking for ideas :)

@xykon Ok, thanks. Downgrading LoPy did the trick, but I still find it very strange that a working setup stops working due to a code problem after +70 hours of normal behavior and no longer starts working even after factory resetting, flashing the latest firmware again and starting again with the exact python project code and firmware... So what should I do next? Wait for a new LoPy firmware when the problem with get_wake_status is resolved? Can I follow some GitHub repository or just follow the forum here on this?

@misterlisty look here https://docs.pycom.io/chapter/datasheets/boards/deepsleep.html To correctly connect a WiPy 2.0, LoPy or SiPy to the Deep Sleep Shield, align the white triangle on the Shield with the LED of the Pycom Device. Once the Pycome Device is seated onto the Deep Sleep Shield, this can then be connected to the Exapnsion Board.

I suffer the same error with the new firmware version (1.10.2.b1). It seems they have not solved it until now... Have you found any solution?+ Thanks

I'm using an Lopy4 powered by a Lifepo4 battery. For testing purposes I'm reading a sensor (bme280), sending the data using lora and then going to sleep for about 10 minutes.

@jcaron I did not try those modifications as calling lora.power_mode(LoRa.SLEEP) before machine.deepsleep() made transmission reliable. On the other hand it may be possible that without this precaution ESP32 enters deep-sleep before transmission is finished.

Guys, thanks for the valuable input. We will create the "best practices for deepsleep" section in the docs and also improve the behaviour of the deinit() methods. Cheers, Daniel

@daniel @bucknall Ping! This is the same issue as: https://github.com/pycom/pycom-micropython-sigfox/issues/68

@robert-hh Thanks for confirmation. With the uCurrent tool I measured current in order of tens of nA but I was not sure if measurement of such small currents makes sense.

@ledbelly2142 Hi ledbelly2142 I am doing a project with the same devices as you. I am a begineer of IoT and it seems I can learn something from your experience. May you share the whole code you have done of this deep sleep shield connected with LoRa, if you still have it. Thanks in advance! Regards Rachel

@andy12 said in Lopy with pysense shield + deep sleep issues: wake_s = ds.get_wake_status() Hi, I have the same problem, maybe Did you resolve it?

@bnjroos I'm definitely not an EE, but you may want to have a circuit where you use both VDD or 3V3 and a GPIO pin as inputs. When VDD/3V3 are off, just ignore completely the GPIO pin (open circuit) and set the output to whatever state you need. When they're on, they you can use the GPIO pin (directly or indirectly) to control the output.

Did you ever find an answer to this? What is the maximum number of seconds for the go_to_sleep() method?

@daniel the failure is on the first wake-up. I don't have a multimeter handy, but can do that this evening. I added @jojo suggestion and the board wakes now. I have left it in a sleep wake cycle and will see how long it runs.

Hi @bucknall, My code does this: uart = UART(1, baudrate=9600) The deepsleep.py library does this: self.uart = UART(1, baudrate=10000, pins=(COMM_PIN, )) I did not expect the deepsleep library to use UART, hence the initial confusion. The docs state there are two UARTs on the LoPy but i did not find out how to differentiate the two yet (I'm still new to micropython). My current workaround is to re-initialise the UART every time it is used. I will revisit this issue when the following blocking issue is solved: https://forum.pycom.io/topic/1685/lopy-with-deep-sleep-shield-hangs-after-x-go_to_sleep-commands